Add fetch metadata module - #2271

Fail-open on unrecognized values, not just absent ones.

SecFetch.of() returns null if any of Sec-Fetch-Site / -Mode / -Dest carries a value not in the corresponding enum (and also when Sec-Fetch-User is present with a value other than ?1). Since this rule runs first (order 100) and is enabled by default, a real browser request carrying a destination micronaut-http doesn't know is fully exempted from the policy instead of being evaluated.

That isn't hypothetical: io.micronaut.http.Destination currently has no webidentity (FedCM), dictionary, webbundle, or sharedstorageworklet, and the Fetch spec's destination list only grows. Every future browser addition silently widens the hole, and nothing here will fail loudly when it happens.

Sec-Fetch-Site alone is the signal for "client is not Fetch-Metadata-aware". Suggest keying on its absence directly:

if (!request.getHeaders().contains(HttpHeaders.SEC_FETCH_SITE)) {
    return FetchMetadataRuleResult.ALLOWED;
}
return FetchMetadataRuleResult.UNKNOWN;

A request with Sec-Fetch-Site: cross-site and an unparseable Dest then falls through to the remaining rules and gets rejected — fail-closed. The docs do describe today's behaviour ("absent, incomplete, and unrecognized"), so this is a deliberate call rather than an oversight, but I think it lands on the wrong side of the trade-off for a security default.

No enable/disable toggle, unlike the other five built-in rules.

Every sibling rule has a @Requires(property = ...) plus a matching accessor on FetchMetadataRulesConfiguration. This one has neither — and it's also missing the @Requires(classes = HttpRequest.class) guard the others carry.

That matters because this is the most permissive built-in rule: it allows cross-site GET navigations including frame/iframe destinations. It's exactly the rule an application hardening beyond the default policy would want to switch off, and right now there's no way to do that short of not using the module.

Suggest micronaut.security.fetch-metadata.rules.allow-simple-navigation (default true) for symmetry.

Follow-on from the SimpleTopLevelNavigationAndIframingFetchMetadataRule comment: this interface exposes a toggle for five of the six built-in rules. Adding isAllowSimpleNavigation() here (plus the property and setter) would make the configuration surface complete and self-consistent.

This duplicates CorsFilter's private validation logic and will drift.

matchesOrigin and matchesMethod are near-verbatim reimplementations of micronaut-http-server's CorsFilter (5.1.12, lines 406-412, 423, 431-436) — right down to the allowedOriginsRegex.isEmpty() && isAny(...) subtlety, which is subtle enough that nobody will notice when it changes upstream.

Two consequences:

1. It already diverges — CorsFilter additionally applies shouldDenyToPreventDriveByLocalhostAttack, which this copy omits, so the Fetch Metadata exemption is slightly more permissive than the CORS filter it claims to stay aligned with.
2. Any future change to core's CORS semantics leaves this stale, silently and in the permissive direction.

Better options, roughly in order of preference: push a public helper into micronaut-core (CorsUtil.isOriginAllowed(config, origin) / isMethodAllowed(...)) and call it from here, or key the exemption off a request attribute that CorsFilter sets, rather than re-deriving the decision.

Minor, while you're in here: Pattern.matches(regex, origin) on line 81 recompiles the pattern on every cross-origin request.

CorsUtil is used on line 94 but isn't listed in @Requires(classes = ...). In practice all three classes ship in the same artifact so this can't actually blow up, but the list reads as if it's exhaustive — worth adding for consistency.

A 403 from a security filter is usually worth more than TRACE. As it stands an operator debugging a blocked client sees an unexplained 403 with nothing in the logs at default levels.

Suggest DEBUG for the rejection paths (keeping TRACE for the approvals), and including the actual Sec-Fetch-Site / -Mode / -Dest values in the message — that's the first thing anyone will want when triaging.

The rejection is a bare 403 with no body and no extension point. Elsewhere in this repo rejections go through RejectionHandler, so applications can render a page, redirect, or add a header.

Even just a @DefaultImplementation-backed seam here would let applications customize the response without forking the filter.

Typo: headers.. — double period.

See my comment on FetchMetadataFilterConfigurationProperties: this api dependency exists solely for a @NotBlank that never gets evaluated. If the annotation goes, this can go with it.

The simple-navigation rule allows cross-site GET navigations with frame/iframe destinations — i.e. the default policy permits the application to be iframed cross-site. That matches the web.dev reference policy, so no complaint about the behaviour, but the table row ("except object and embed") makes it easy to read the opposite.

Worth one sentence noting that framing protection still requires CSP frame-ancestors or X-Frame-Options, so nobody assumes this module covers clickjacking.